Techniques for processing customer service transactions at customer site using mobile computing device

ABSTRACT

Techniques are described for facilitating delivery and adjustments of customer orders at a customer delivery site. A delivery courier is assigned a mobile field computing device for facilitating delivery and order adjustments of customer orders associated with that courier&#39;s delivery route. The mobile field computing device includes memory for storing customer order history data and delivery route data downloaded from a server system. The delivery route data stored in the mobile field computing device may be used by the delivery courier to facilitate delivery of the customer orders. Further, the delivery courier may use the mobile field computing device to process a variety of different order adjustment transactions at a customer delivery site.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/568,572 entitled “TECHNIQUE FOR PROCESSING CUSTOMER SERVICETRANSACTIONS AT CUSTOMER SITE USING MOBILE COMPUTING DEVICE,” filed May10, 2000, the entirety of which is incorporated herein by reference forall purposes, which claims priority under 35 USC 119(e) from U.S.Provisional Patent Application No. 60/133,646, entitled ELECTRONICCOMMERCE ENABLED DELIVERY SYSTEM AND METHOD, filed May 11, 1999, theentirety of which is incorporated herein by reference for all purposes.

The present application also relates to a number of U.S. patentapplications filed in May 2000, including: U.S. patent application Ser.No. 09/568,603 for INTEGRATED SYSTEM FOR ORDERING, FULFILLMENT, ANDDELIVERY OF CONSUMER PRODUCTS USING A DATA NETWORK; U.S. patentapplication Ser. No. 09/568,570 for INVENTORY REPLICATION BASED UPONORDER FULFILLMENT RATES; U.S. patent application Ser. No. 09/568,614 forREAL-TIME DISPLAY OF AVAILABLE PRODUCTS OVER THE INTERNET; U.S. patentapplication Ser. No. 09/568,613 for SCHEDULING DELIVERY OF PRODUCTS VIATHE INTERNET; U.S. patent application Ser. No. 09/568,823 for LOADBALANCING TECHNIQUE IMPLEMENTED IN A DATA NETWORK DEVICE UTILIZING ADATA CACHE; U.S. patent application Ser. No. 09/568,569, now U.S. Pat.No. 6,622,127 B1, for ORDER ALLOCATION TO SELECT FROM INVENTORYLOCATIONS STOCKING FEW UNITS OF INVENTORY; U.S. patent application Ser.No. 09/566,912, now U.S. Pat. No. 6,332,334 B1, for METHOD AND APPARATUSFOR HANDLING AND TRANSPORTING TEMPERATURE-SENSITIVE ITEMS; and U.S.patent application Ser. No. 09/568,571 for ORDER ALLOCATION TO MINIMIZECONTAINER STOPS IN A DISTRIBUTION CENTER. Each of the disclosures ofthese copending applications is incorporated herein by reference in itsentirety for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of electronic commerce. Inparticular, the present invention relates to a technique for deliveringand modifying customer orders for consumer products using a datanetwork.

2. Description of the Related Art

Companies have been delivering goods to customer homes for years usingmany different kinds of delivery systems. Examples run from mail ordercatalog shopping to on-line ordering and delivery services such as thoseprovided by Amazon.com and Peapod.com. Indeed, the demand for homeshopping and home delivery is increasing. However, many of theconventional systems which provide home shopping and home deliveryservices have significant limitations that prevent their adoption on alarge scale basis.

Using conventional techniques, an on-line product purchasing transactionwill typically include the following steps. First, the customer selectsone or more products to be purchased. Once the customer has finishedselecting the desired product(s), the customer may then proceed to acheck-out or order confirmation page. During the check-out or orderconfirmation process, the customer provides the necessary informationfor completing the transaction purchase, such as, for example, thecustomer's name, credit card number, shipping address, etc. Before theorder is confirmed by the on-line retailer, (e.g., Amazon.com), thebilling and financial information is verified and processed. Forexample, if a credit card is used by the customer to purchase selectedon-line products, a credit card transaction for the total amount of thepurchase will be authorized before the purchase order is confirmed andfulfilled by the merchant. Once the payment transaction has beenauthorized, the on-line merchant typically fulfills the order byobtaining the purchased products, and shipping the purchased productsthe customer's shipping address using a common carrier (e.g. third-partycourier) such as, for example, UPS, USPS, Federal Express, etc. Thecustomer's credit card is typically billed at the time of shipment.

Although conventional on-line product purchasing techniques provide theconvenience of allowing a customer to purchase and receive a desiredproduct without having to venture outside his or her home, thesetechniques suffer from a number of disadvantages. For example, manyon-line merchants provide adequate customer service relating to on-lineproduct purchases, but typically provide inadequate customer service forhandling returns or customer complaints. Further, once the customer'sorder has been processed, a customer typically does not have the abilityto change, alter, or cancel the order. Rather, the customer musttypically wait until he or she receives the originally ordered goods,and then must make a subsequent request to the on-line merchant forreturning or modifying at least a part of the order. This latter requestis typically handled as a separate transaction on the merchant's side,and may involve lengthy delays. Additionally, if the customer wishes toreturn one or more products, the customer is typically required by themerchant to first obtain a return authorization number (after firstsubmitting a return request), and typically is responsible for payingshipping costs for shipping the returned products back to the merchant.

The following example may help to illustrate some of the potentialproblems which a customer may encounter when purchasing products viaon-line retailers or merchants. First, let us assume that a customer hasselected two books for purchase using an on-line merchant, such as, forexample, Amazon.com. When the customer proceeds to the check-out page,the customer authorizes a total amount (i.e., for the books, tax, andshipping) to be billed to his or her credit card. Once the credit cardauthorization for the total amount has been received, the merchantfulfills the order and forwards the order to a common carrier forshipment. The customer's credit account will be billed at this time forthe total amount specified above.

After the order has been fulfilled by the merchant, the customer istypically unable to modify or cancel the order. Thus, for example, ifthe customer subsequently wishes to cancel one of the ordered booksafter the merchant has fulfilled the order, the customer must first waitto receive the book, and then submit a separate request to the on-linemerchant for returning the book. It is worth noting that since thepurchased items are typically shipped using an independent courierservice or common carrier such as UPS, Federal Express, or the U.S.postal service, there is no mechanism in place whereby the customer isable to return the undesired product (e.g., book) back to the deliverycourier for an immediate refund. Rather, as is typically the case, thecustomer must first obtain a return authorization number from themerchant, re-package the unwanted product, and ship the unwanted productback to the merchant. Typically, the customer is required to pay forshipping charges for returning a product, even if the product wasreceived in a defective condition.

Once the returned product is received by the merchant, it is typicallyprocessed within four to six weeks, meaning that a credit for thereturned product may not be issued to the customer until four weeksafter the product has been received by the merchant. In the exampleabove, a credit, when issued, may appear as a refund or a credit on thecustomer's credit card account.

An additional problem with conventional on-line purchasing transactionsrelates to merchandise availability. For example, when a merchantreceives a request for a product return, the merchant is not able toinclude the returned product as part of the merchant's current inventoryuntil the returned product is physically received at the merchant's siteand the return processed, which may take up to 4 to 6 weeks. Moreover,until the returned order is processed, the returned merchandise willtypically not be included as part of the inventory made available forcustomer purchase. This results in an inefficient allocation ofresources.

In light of the above, there exists a continual need to improve uponelectronic commerce and on-line purchasing and delivery techniques.

SUMMARY OF THE INVENTION

According to the several embodiments of the present invention,techniques are described for facilitating delivery and adjustment ofcustomer orders at one or more customer delivery sites. According to oneembodiment, a delivery courier is assigned a mobile field computingdevice for facilitating delivery and order adjustments of customerorders associated with that courier's delivery route. The mobile fieldcomputing device can include memory for storing customer order historydata and delivery route data downloaded from a server system. Thedelivery route data stored in the mobile field computing device may beused by the delivery courier to facilitate delivery of the customerorders. Further, the delivery courier may use the mobile field computingdevice to process a variety of different order adjustment transactionsat a customer delivery site.

Additional objects, features and advantages of the various aspects ofthe present invention will become apparent from the followingdescription of its preferred embodiments, which description should betaken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic block diagram of an integrated systemarchitecture 100 in accordance with a specific embodiment of the presentinvention.

FIG. 1A shows a schematic block diagram of a system which may be usedfor processing customer service transactions at the customer site inaccordance with a specific embodiment of the present invention.

FIG. 2 shows a flow diagram of an MFD Download Procedure 200 inaccordance with a specific embodiment of the present invention.

FIG. 3 shows a flow diagram of an MFD Field Processing Procedure 300 inaccordance with a specific embodiment of the present invention.

FIG. 4 shows a flow diagram of an MFD Upload Procedure 400 in accordancewith a specific embodiment of the present invention.

FIG. 5 shows a flow diagram of a specific embodiment of the presentinvention, illustrating various data flows which may occur between anMFD Client 106 a, and MFD Server 112, and a Webstore Data Base 131 ofFIG. 1.

FIG. 6 shows a block diagram of a mobile computing device (MFD) inaccordance with a specific embodiment of present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The technique of the present invention provides a solution forfacilitating delivery and adjustments of customer orders which may beperformed by a delivery courier at a customer delivery site. Accordingto at least one embodiment, each delivery courier is assigned a mobilefield computing device (MFD Client) for facilitating delivery and orderadjustments of customer orders associated with that courier's deliveryroute. Before being dispatched to commence his or her delivery run, thedelivery courier may download customer order history data and deliveryroute data from an MFD Server into the courier's MFD Client device. Thedelivery route data stored in the MFD Client device may be used by thedelivery courier to facilitate delivery of the customer orders. Further,the delivery courier may use the MFD Client device to process a varietyof different order adjustment transactions (e.g. customer returns, ordermodifications, fees, credits, etc.) at a customer delivery site. The MFDClient device may be configured to use the stored customer order historydata to process the order adjustment transactions. Additionally, the MFDClient device may further be configured to compute updated customerbilling data based upon the processed order adjustment transactions. Amodified receipt which includes the updated customer billing data maythen be provided to the customer. In this way, the customer will know,at the time of delivery, all charges for which the customer will bebilled and/or credited. Additionally the technique of the presentinvention may be used to track the status of customer orders anddelivery resources such as, for example, delivery couriers and/ordelivery vehicles.

FIG. 1 shows a schematic block diagram illustrating various systems,subsystems and/or components of the integrated system architecture 100in accordance with a specific embodiment of the present invention. Asshown in FIG. 1, system 100 includes a plurality of subsystems and othercomponents for effecting electronic commerce over a data network. Abrief description of at least a portion of the plurality of subsystemsof system 100 is presented below. For example, system 100 of FIG. 1 mayinclude:

(1) a Webstore Subsystem (WS) 132 which manages the on-line storeinterface with customers, including customer shopping and orderingtransactions;

(2) a Transportation Subsystem (XPS) 124 which manages delivery windowscheduling, delivery vehicle routing, capacity planning, and mobilefield device (MFD) data used by delivery couriers;

(3) an Order Management Subsystem (OMS) 150 which manages pricing data,item availability data, inventory data, vendor data, finance,procurement, etc;

(4) an Order Fulfillment Subsystem (OFS) 160 which facilitates thefulfillment of customer orders and manages the distribution center (170)operations;

(5) a Customer Relationship Management (CRM) Subsystem 126 for enablingcustomer service representatives (CSRs) 143 to service customer requestsand track customer interaction; etc.

As shown in FIG. 1, system 100 may include at least a portion of theabove-described subsystems. Additionally, each subsystem may alsocomprise at least one server and/or other components. Further, eachsubsystem may be configured to utilize a dedicated or shared databaseserver as its persistent and transactional data backbone. Users orcustomers may access data stored on one of the subsystem's databaseservers (e.g. Webstore database), which then executes appropriatebusiness logic and/or business objects.

Each subsystem may be configured or designed to communicate with eachother via a plurality of interfaces. According to a specific embodiment,the plurality of interfaces includes both synchronous and asynchronousinterfaces. Many of the various system interfaces are configured to beasynchronous, wherein data is typically transferred in batch mode viastaging (e.g. database) tables or flat files (e.g., separated valuefiles). However, at least a portion of the system interfaces areconfigured as synchronous interfaces. Generally, a synchronous interfacemay be used where an immediate response from a server or component isrequired. Synchronous interfaces in the system 100 of FIG. 1 may existbetween the WS 132 and Tax Server 114, and MFD Server 112 and Tax Server114, for example.

Conceptually, the system 100 of FIG. 1 may be grouped into two generalsubsystems, namely a Front Office system and a Back Office system. TheFront Office system is generally responsible for functions related tocustomer transactions such as, for example, customer orders, billingtransactions, delivery scheduling, customer service, etc. In theembodiment of FIG. 1, for example, the Front Office system 130 comprisesthe Webstore Subsystem 132, Transportation Subsystem 124, and CustomerRelationship Management Subsystem 126. The Front Office system 130 mayalso include other subsystems or components such as, for example, aMobile Field Device (MFD) Server 112, a tax component 114, a credit ordebit card billing component 116, a Help Desk component 144, etc. Theabove-described subsystems and components of Front Office 130 aredescribed in greater detail below.

Additionally, the Front Office system 130 may include a centralizeddatabase 131 which may be accessed by subsystems and/or components ofsystem 100. Alternatively, one or more of the Front Office systemsand/or components may each comprise a respective database which isaccessible by other subsystems and/or components of system 100.

The Back Office system generally includes all subsystems and/orcomponents which are not part of the Front Office system. Thus, as shownin FIG. 1, for example, the Back Office system includes the OMS 150 andOFS 160 subsystems. However, the invention is not limited to theparticular embodiment shown in FIG. 1, and it will be appreciated thatthe specific configuration of system 100 may be modified by one havingordinary skill in the art to suit specific applications.

Subsystem Functionality

This section provides a more detailed description of the varioussubsystems and components which form the integrated system architectureof the present invention, as shown, for example, in FIG. 1 of thedrawings.

Front Office Architectural Layers

As shown in FIG. 1, the Front Office system 130 comprises a plurality ofseparate subsystems such as, for example, Webstore Subsystem (WS) 132,Transportation Subsystem (XPS) 124, and Customer Relationship Management(CRM) Subsystem 126. Each subsystem may be implemented via a combinationof hardware and/or software, and further may include a plurality ofdifferent functional components, modules, and/or plug-in applications.

At least a portion of the software residing at the Front Office systemmay include a presentation layer, an application layer, a businessobject layer, a database access layer, or any combination thereof.According to a specific embodiment, the presentation layer handles theactual presentation of information to users via an appropriate medium.The application layer, which may be stateless, handles the appropriateapplication logic for the various subsystems of the Front Office. Forexample, in the Webstore Subsystem 132, it is the application layer(referred to as the shopping engine) which determines that a customercannot check out an order unless the customer has selected a deliverywindow, or provided billing information. The business object layer,which may be stateful, provides objects with a fixed set offunctionality (e.g. methods or procedures) that may be manipulated bythe application layer. The business object layer may also implementwrite through caching of data. According to a specific embodiment, thebusiness objects do not know about each other, and the application layerhandles the coordination between the various business objects. Thedatabase access layer provides connectivity and data access APIs to theFront Office database 131 (also referred to as the Webstore database).According to a specific embodiment, the database access layer performspooling and caching of connection objects, where appropriate.

It is also important for a common database schema to be adopted by eachof the Front Office systems. According to a specific embodiment, thedatabase 131 is implemented as a shared database which may be accessedby each of the Front Office systems.

Webstore Subsystem (WS)

The Webstore Subsystem (WS) 132 provides an interface for enablingcustomers to access the on-line store (e.g. Webstore). In a specificembodiment where the Webstore is implemented as a website on the WorldWide Web, customers may access the Webstore via the Internet or WorldWide Web using any one of a plurality of conventional browsers. TheWebstore user interface may be designed to provide a rich set offunctions without requiring any special browser plug-ins. Thus,according to a specific embodiment, customers may access the Webstoreusing any client machine, regardless of the machine's operating systemplatform. Additionally, for security purposes, the Webstore interfacealso supports data encryption for exchange of any sensitive or privateinformation between the customers and the website. According to aspecific embodiment, the secure Webstore interface is implemented usinga secure http protocol (HTTPS), commonly known to those of ordinaryskill in the art.

In accordance with a specific embodiment, the Webstore Subsystem 132supports a number of customer related features such as, for example,self registration; accessing of customer account information; browsingof product categories and category hierarchy; viewing of product imagesand product information; keyword searches; delivery scheduling;accessing of customer order history; customizable shopping lists;on-line shopping and ordering; etc.

The Webstore Subsystem (referred to as the Webstore) may be implementedusing at least one server which is connected to the data network.According to a specific embodiment, the Webstore is implemented using aplurality of web servers (e.g. web server farm) which helps to minimizeserver response time and provide real-time failover and redundancycapabilities. Further, according to a specific embodiment, in order tokeep the web server response time to a minimum, the Webstore may beconfigured such that all processing is performed on a single server,within one process. Where a plurality of Webstore servers are used,redundant processing may be performed by at least a portion of theservers so that a single Webstore server may handle all Webstoreprocessing tasks associated with a particular on-line customer. It willbe appreciated that the Webstore server boundaries may be crossed whereappropriate, such as, for example, when accessing the Front Officedatabase via the data network.

Additionally, as shown in FIG. 1, the Front Office system may include anumber of integrated components which provide additional functionality.For example, the WS may include a plurality of components which provideadditional functionality such as, for example, computation of taxes,search capability, credit card billing, etc. Thus, as shown in FIG. 1,for example, the WS 132 includes a tax computation component 114 forcomputing taxes for each order line item that is sold, and a credit (ordebit) card server (CC) component 116 for handling credit and/or debitcard authorizations and funds captures. According to at least oneembodiment, one or more of these components may be implemented as anasynchronous process in order to reduce or minimize impact on theWebstore server's response time and availability.

Transportation Subsystem (XPS)

The Transportation Subsystem (XPS) 124 generally handles delivery windowscheduling, delivery vehicle routing, capacity planning, and mobilefield device programming used by delivery couriers. Accordingly, theTransportation Subsystem may be configured to provide the followingfunctional features: (1) delivery scheduling, and delivery windowreservation; (2) deliveries to customer site with appropriate billingactions and processing, including processing of adjustments, credits,and returns; and (3) adjusting delivery operation parameters such as,for example, truck route plans, delivery vehicle usage, serviceduration, parking time, delivery courier scheduling, data to bedownloaded into MFDs, etc.

As shown in FIG. 1, for example, the Transportation Subsystem 124 maycomprise a plurality of components and/or other subsystems including MFDServer(s) 112, mobile field client devices (MFD Clients) 106, anddelivery couriers 110. In alternate embodiments, at least a portion ofthese components such as, for example, the MFD Server 112, may beimplemented as a separate subsystem and may reside external to theTransportation Subsystem.

One function of the Transportation Subsystem is to generate a list ofavailable delivery windows (for presentation to the customer) based upontransportation capacity data such as, for example, the number ofcouriers available, the number of delivery vehicles available, thenumber of orders for a particular day, truck routes, etc.

Dispatch Subsystem (DS)

According to at least one embodiment, the Transportation Subsystem mayinclude a Dispatch Subsystem 107 for allowing real-time access to thestate and/or status of delivery couriers and delivery vehicle resources.Using the Dispatch Subsystem, dispatchers may communicate with deliverycouriers that are en-route, and may also use the Dispatch Subsystem toprovide real-time re-scheduling of delivery routes. According to aspecific embodiment, the Dispatch Subsystem may be implemented via theMFD Subsystem (described in greater detail below).

Customer Relationship Management (CRM) Subsystem

The Customer Relationship Management Subsystem 126 is an interactiveapplication which may be used by customer service representatives (CSRs)143 to manage customer service requests and to track customerinteraction. The functionality provided by the CRM subsystem mayinclude, for example, accessing customer information; issuing creditsfor various customer issues (e.g. complaints, returns, damaged goods,etc.); handling work flow for processing customer issues; etc. The CRMsubsystem provides CSRs (sometimes referred to as customer serviceoperators—CSOs) with the ability to access, view, and edit customerinformation in accordance with customer requests.

The general architecture of the CRM Subsystem is similar to that of theWebstore Subsystem. For example, in a specific embodiment, the CRMsubsystem may use the same application, business object, and databaseaccess layers which is used by the Webstore Subsystem.

In the embodiment shown in FIG. 1, the CRM subsystem comprises a HelpDesk component 144. In a specific implementation, the Help Deskcomponent is implemented using the Remedy software package, manufacturedby Remedy Corp., of Mountain View, Calif. The Help Desk componentmanages any workflow for handling specific customer requests or issues.For example, the Webstore and Transportation Subsystems may generatetrouble tickets for various events such as, for example, failed creditcard authorizations or customer-reported shorts in delivery. The CSRsprocess these trouble tickets via the Help Desk component 144 of the CRMsubsystem. Utilizing the Help Desk component, the CSRs are able toinitiate and track any customer contact relating to the processedtrouble tickets. The CSRs may access the Help Desk component 144 via aHelp Desk GUI 142.

According to a specific embodiment, the Help Desk component includes adatabase 145 for managing customer service requests and/or issues.Alternatively, the Help Desk component may be configured to share theFront Office database 131.

Order Management Subsystem (OMS)

The Order Management Subsystem (OMS) 150 manages a variety of aspectsrelated to the integrated system architecture of the present invention,including, for example, pricing, availability, inventory, vendors,financials, procurement, and data flows between various subsystems. Asshown in FIG. 1, the OMS subsystem 150 includes graphical user interface152, and at least one database 151 for storing various data receivedfrom at least a portion of the other subsystems.

The Order Management Subsystem is also configured to include appropriatesoftware and/or hardware for managing financial and distributionapplications. According to a specific embodiment, the financial anddistribution software is provided by PeopleSoft Corporation ofPleasanton, Calif. Additionally, the financial and distributionapplication software may include a plurality of components such as, forexample, a user interface used for inquiry and on-line transactionentry, batch processes used for background processing of data, reports,etc.

The OMS batch processing may be controlled using a process scheduler.The process scheduler is able to manage the number of concurrentprocesses being run and the date/time at which certain processes are torun or be executed. The process scheduler may also enable centralvisibility of all processes currently running. Batch processing andreporting may be accomplished using a variety of different technologiescommonly known to one having ordinary skill in the art.

The Order Management Subsystem may be configured to support bothasynchronous and synchronous interfaces with the other subsystems. In aspecific embodiment, the OMS is configured to support an asynchronousinterface with each of the other subsystems. Additionally, each OMSinterface is configurable, and may be configured to support the runningof batch processes as often as is desirable.

Order Fulfillment Subsystem (OFS)

The Order Fulfillment Subsystem 160 manages all functionality of thearea distribution center (DC) 170. In the embodiment of FIG. 1, the OFSincludes appropriate hardware and/or software for managing the DCfacility 170, including, for example, a warehouse management system(e.g. software application), and at least one database 161. Thewarehouse management subsystem may also provide the interface forallowing the OMS subsystem to communicate with the OFS database 161.

Mobile Field Device (MFD) Subsystem

Although the MFD Server 112 may conceptually be grouped with theTransportation Subsystem, in a specific embodiment, the MFD Servercomponent 112 may configured to include at least one back-end serverwhich resides in a particular area data center. Thus, different areasmay be serviced by different MFD Servers. Moreover, each zone in aparticular area may serviced from a station which may be connected tothe area data center via the data network. Each MFD Client 106 maycommunicate with an area MFD Server 112 via the data network, anddownload and/or upload various types of information, including, forexample, customer order history information, delivery information (e.g.vehicle delivery routes, stops, etc.), customer returns information,credits, adjustments, etc.

According to a specific implementation, each delivery courier carries anMFD Client while making his or her delivery run to the customer sites.During delivery, the MFD Client 106 may be configured to provide thedelivery courier with delivery route information, including deliveryroutes and stops. Additionally, the MFD Client may also be configured toverify delivered items upon delivery. Further, using the MFD, thedelivery courier is able to immediately process a variety of customerservice requests at the customer site (e.g. at the time of delivery tothe customer), such as, for example, order modifications, customerreturns, billing adjustments, inventory adjustments, credits, etc.According to a specific embodiment, the MFD Client is able to processthese various customer service requests using data stored within thedevice, which has been downloaded into the MFD unit prior to thedelivery. Thus, according to this embodiment, the MFD Client does notcommunicate with the MFD Server while processing the customer servicerequests at the delivery site. Alternatively, however, the MFD Clientmay be configured to communicate with the area MFD Server duringprocessing of the customer service request using any one of a number ofstandard mobile communication techniques such as, for example, RF datasystems, cellular data systems, etc. In this latter embodiment, the MFDClient may also be configured to allow processing of customer servicerequests, even at times when the MFD Client is temporarily unable tocommunicate with the MFD Server. To accomplish this, the customer MFDdata is previously downloaded into the MFD Client at a time when the MFDClient is able to communicate with the MFD Server.

After the MFD has processed all appropriate transactions at the customerdelivery site (including verification of current ordered items receivedby the customer), the MFD may also be configured or designed to providethe customer with an adjusted billing receipt (i.e. zero balancereceipt), showing a total amount to be billed which takes into accountany billing adjustments related to any processed returns, credits,adjustments, etc.

After completing deliveries on the delivery route, the courier, uponreturning to the station, may connect the MFD Client 106 to the MFDServer 112, and upload all of the processed field transactions into thearea data center, where it is then processed and stored in the FrontOffice database 131. The uploaded MFD data may also include the times atwhich the delivery events occurred.

According to a specific embodiment, the customer is not billed for thedelivered order until after the order has been delivered and the MFDdata relating to the delivery has been received at the Front Officesystem. The customer will then be billed for the adjusted total amountto be billed, indicated on the adjusted billing receipt (which waspresented to the customer at the time of delivery). In this way, thecustomer will know, at the time of delivery, all charges for which thecustomer will be billed.

FIG. 1A shows a block diagram of a portion of the system 100 of FIG. 1,which includes an MFD Server 112, a plurality of MFD Clients 106, and aplurality of delivery couriers 110. As described previously, the MFDServer 112 may be configured to include at least one back-end serverwhich resides in a particular area data center. Thus, or example,according to one embodiment, the MFD Server 112 physically resides atthe Front Office Subsystem 130 (FIG. 1).

According to a specific embodiment, a logical MFD Server may beimplemented to handle the back-end transactions processed by the mobilefield devices (MFDs) assigned to a specific distribution area. Thus, forexample, in the embodiment of FIG. 1A, MFD Server 112 may handle all MFDtransactions associated with a specific area distribution center (e.g.,area DC 170, FIG. 1). In one embodiment, each area distribution centermay service one or more local cross-dock stations in that area. Eachcross-dock station (herein referred to as “station”) provides localservice to customers residing in designated delivery zones. Customerorders which are fulfilled by the distribution center (170, FIG. 1) maybe off-loaded to an appropriate station where the order may then bedelivered to the customer using a local delivery vehicle and courier110. For example, referring to FIG. 1A, couriers 1 and 2 (110 a, 110 b)may be associated with a first station, and courier N (110 n) may beassociated with a second station. Each of the plurality of couriers 110is assigned a respective delivery route. Additionally, each of theplurality of couriers is assigned a respective mobile field device (MFD)(also referred to as an MFD Client) for processing customer servicetransactions that take place on that courier's delivery route. Thus, inthis example, MFD Server 112 will be configured to handle the back-endtransactions for all MFD Clients 106 within a designated distributionarea. According to a specific implementation, the MFD Server 112 may bedeployed using a plurality of servers that have been configured tooperate on a networking platform such as, for example, Windows NT, Unix,etc. Together, the plurality of servers may form the logical MFD Server112 of FIG. 1A.

The plurality of MFD Clients (106 a, 106 b, 106 n) of FIG. 1A correspondto mobile computing devices which are used by the plurality of couriers110 to process transactions at the customers' delivery site. Each MFDClient may be configured to run on a variety of different operatingsystems such as, for example, DOS, PALM O/S, etc. According to oneimplementation, an MFD Client may be implemented using a mobilecomputing device such as the PC-based Telxon 1124 device manufactured byTelxon Corporation of Akron, Ohio. According to an alternate embodiment,the MFD Client may be implemented using a PDA-type device such as theSymbol SPT 1700, manufactured by Symbol Technologies of Holtsville, N.Y.

Generally, the MFD Client and Server devices of the present inventionmay be implemented via software and/or hardware. A software orsoftware/hardware hybrid MFD Server system of this invention ispreferably implemented on a general-purpose programmable machineselectively activated or reconfigured by a computer program stored inmemory. Further, the MFD Server may have multiple network interfaces forcommunicating with MFD Clients via a local or wide area network. In analternative embodiment, the MFD Server system may be implemented on ageneral-purpose network host machine such as a personal computer orworkstation. According to a specific implementation, the MFD Server maybe configured to simultaneously communicate with multiple MFD Clients.Further, the invention may be at least partially implemented on a card(e.g., an interface card) for a network device or a general-purposecomputing device.

Similarly, each MFD Client may be implemented using a software/hardwarehybrid mobile computing device such as, for example, the handheldcomputing devices described previously. Referring to FIG. 6, a specificimplementation of a mobile computing device 60 is shown which issuitable for implementing the MFD Client device of present invention. Asshown in the implementation of FIG. 6, the MFD Client device 60 includesa master central processing unit (CPU) 62, one or more interfaces 68,and a bus 67 (e.g., a PCI bus). When acting under the control ofappropriate software or firmware, the CPU 62 is responsible for suchtasks as generating and recording time stamps, storing and displaying ofdelivery route information, storing and displaying customer orderhistory, processing customer service field transactions, etc. The CPUpreferably accomplishes all these functions under the control ofsoftware including an operating system and any appropriate applicationssoftware. CPU 62 may include one or more processors 63 such as aprocessor from the Motorola family of microprocessors or the Intelfamily of microprocessors. In an alternative embodiment, processor 63 isspecially designed hardware for controlling the operations of the MFDClient device 60. In a specific embodiment, a memory 61 (such asnon-volatile RAM and/or ROM) also forms part of CPU 62. However, thereare many different ways in which memory could be coupled to the system.Memory block 61 may be used for a variety of purposes such as, forexample, caching and/or storing data, programming instructions, etc.

Each MFD may also include a scanner (not shown) which may be used, forexample, to scan bar codes or UPC codes. Further, as shown in FIG. 6,each MFD Client may include at least one interface 68 for communicatingwith the MFD Server 112. According to one implementation, the MFD Clientmay be configured to communicate with the MFD Server using a dockingcradle which is connected to the MFD Server via a local or wide areanetwork. Each station may be provided with a plurality of dockingcradles for simultaneously connecting multiple MFDs to the MFD Server112. Alternatively, according to a different implementation, the MFDClient 106 a may be configured to include a wireless LAN transceiver forcommunicating with the MFD Server. In a specific embodiment, eachstation may be provided with one or more transponders for communicatingwith MFDs using a wireless protocol. Each transponder may be configuredto communicate with the MFD Server via a local or wide area network.

According to a specific embodiment, the MFD Client 60 may be implementedon a PDA device such as, for example, a device similar to the well-knownPalm series of PDA devices manufactured by Palm, Inc., of San Jose,Calif. In this embodiment, the MFD Client may be configured to run on aPalm OS platform licensed by Palm, Inc. According to a specificimplementation, a synchronization mechanism may be used to transfer databetween the MFD Server and the MFD Client in a manner similar to the waydata is transferred between a Palm device and a desk top computer usingPalm's HotSync manager software. For example, a client synchronizationprogram running on the MFD Client may serve as the MFD Client agent, anda server software program running on the MFD Server may serve as theserver agent. According to a specific implementation, the server andclient synchronization software may be implemented using softwareprovided by Aether Software, of Vienna, Va. Further, according to aspecific implementation, synchronization may be achieved using a TCP/IPbased protocol.

The MFD Client may be configured or designed to perform a variety ofdifferent functions and may also be configured or designed to retrieve,generate, and/or store a variety of different data relating to one ormore customer orders. For example, the MFD Client may be configured toprocess, at a customer delivery site, transactions relating to a currentand/or previous customer orders, and may further be configured toprocess such transactions in the absence of a communication link betweenthe MFD Client and the MFD Server. Thus, for example, according to aspecific implementation, each MFD Client may be configured or designedto process in-field transactions relating to customer returns, customerorder shorts, credits (e.g., credit for late delivery), fees (e.g.,re-delivery fee), tote deposits/returns, tote verification, customer IDverification, ID checks (e.g., for tobacco/alcohol), coupons and/orpromotional offers, signature capture, printing of zero-balancereceipts, printing of Return Merchandise Authorization (RMA) slips, etc.

Additionally, each MFD Client may be configured or designed to storevarious types of data which may include, for example, customer deliveryaddresses, customer notes and/or instructions, delivery timeinformation, deliver route and/or map information, customer orderhistory, etc. The MFD data downloaded to the MFD Client may also includepre-defined reason codes which may be accessed by the delivery courierto provide an explanation for an adjustment transaction that isprocessed at the customer delivery site.

Customer notes or instructions stored on an MFD Client may include notesfrom delivery couriers, notes from customer service representatives, andmay also include notes from the customer (e.g. special deliveryinstructions) which may be entered by the customer via the Internet.According to a specific embodiment, the MFD Client may be configured toretrieve and store customer order history data for selected customers onthe delivery route. The customer order history may include current orderinformation, as well as past order history information (e.g., within thelast 30 days). The customer order information may include, for example,a price paid for each item as ordered, a quantity of each item ordered,a date that the item was ordered and/or delivered, a SKU numberassociated with each ordered item, a bar code ID associated with eachordered item, and a tax amount (if any) which was paid for each ordereditem. According to a specific embodiment, the MFD Client includes adisplay which may be used for displaying data stored in the memory ofthe MFD Client. In one implementation, the customer order historyinformation stored in the MFD Client may be sorted using a variety ofdifferent criteria such as, for example, by customer order, by date, bySKU, etc.

Further, for processing customer returns, the MFD Client may beconfigured to differentiate between returned goods which are to bereturned to the distribution center (DC) for restocking (for which anRMA slip or “chit” will be printed), and returned goods which are to bescrapped or thrown away (for which no RMA slip will be printed).

The MFD Client and Server devices of the present invention may alsoemploy one or more memories or memory modules (such as, for example,memory block 65) configured to store data, program instructions for theMFD data transactions described herein, etc. The program instructionsmay control the operation of an operating system and/or one or moreapplications, for example. The memory or memories may also be configuredto store the various types of MFD data described in this application,such as for example, customer delivery addresses, customer notes and/orinstructions, delivery time information, deliver route and/or mapinformation, customer order history data, etc.

Because such information and program instructions may be employed toimplement the systems/methods described herein, the present inventionrelates to machine readable media that include program instructions,state information, etc. for performing various operations describedherein. Examples of machine-readable media include, but are not limitedto, magnetic media such as hard disks, floppy disks, and magnetic tape;optical media such as CD-ROM disks; magneto-optical media such asfloptical disks; and hardware devices that are specially configured tostore and perform program instructions, such as read-only memory devices(ROM) and random access memory (RAM). The invention may also be embodiedin a carrier wave travelling over an appropriate medium such asairwaves, optical lines, electric lines, etc. Examples of programinstructions include both machine code, such as produced by a compiler,and files containing higher level code that may be executed by thecomputer using an interpreter.

FIG. 2 shows a flow diagram of a MFD Download Procedure 200 inaccordance with a specific embodiment of the present invention. The MFDDownload Procedure 200 may be initiated, for example, by a deliverycourier before departing the station to deliver orders to customers onthe courier's delivery route. In the example of FIG. 2, it is assumedthat each delivery courier at a particular station has been assigned arespective delivery route. At 202, the delivery courier selects a MFDClient device (herein referred to as “MFD Client”) to receive downloadedMFD data from the MFD Server. According to one embodiment, each deliverycourier may be assigned a specific MFD Client for a specified timeperiod.

After the delivery courier has selected or been assigned a specific MFDClient at the cross-dock station, the delivery courier activates the MFDClient in order to establish (204) a connection with the MFD Server. Inone embodiment, the delivery courier places the MFD Client into a cradlewhich provides a connection to the MFD Server. According to an alternateembodiment, the delivery courier simply depresses a key or switch on theMFD Client to cause the device to establish a wireless connection withthe MFD Server 112. At 206, the delivery courier enters (206) logininformation and a route ID corresponding to that delivery courier'sassigned delivery route. Once the login and route ID data has beenverified by the MFD Server, the MFD Server retrieves MFD data relatingto the identified route ID, and downloads (208) the appropriate MFD datainto the memory of the MFD Client. The various data flows which mayoccur between the MFD Client and MFD Server during the MFD DownloadProcedure 200 are described in greater detail with respect to FIG. 5 ofthe drawings.

After the appropriate MFD data has been downloaded into the courier'sMFD Client, the courier then verifies (210) the deliverable totes forthat courier's delivery route. According to a specific embodiment, thedelivery tote verification may be accomplished using the MFD Client toscan the bar-coded license plates of all delivery totes at the stationwhich have been assigned to the delivery courier. The MFD Client may beused to verify that all delivery totes are accounted for before thecourier is dispatched from the station. If all deliverable totes are notaccounted for, the MFD Client may display to the delivery courier theIDs of the missing totes. In the event that the missing totes are not tobe found at the cross-dock station, the items from the missing toteswill be processed as shorts for the associated customer order(s). Afterverifying the deliverable totes associated with his or her deliveryroute, the delivery courier may then be dispatched (212) from thestation to deliver the totes to the awaiting customers.

According to a specific embodiment, each delivery route includes aplurality of stops which correspond to specific customer deliveryaddresses. Further, each stop in the delivery route may correspond to aspecific customer order.

FIG. 3 shows a flow diagram of an MFD Field Processing Procedure 300, inaccordance with a specific embodiment of the present invention. The MFDField Processing Procedure 300 may be initiated at each stop on acourier's delivery route. At 302, the delivery courier arrives at adelivery stop corresponding to a specific customer order, and notes thearrival time. According to a specific embodiment, when the deliverycourier arrives at a specific delivery stop, the courier depresses a keyon the MFD Client, which causes the MFD Client to record the arrivaltime of the courier at the specified stop. The delivery courier may thenunload and scan (304) the appropriate totes for customer orderassociated with that delivery site. Each tote may be scanned using theMFD Client. Once the appropriate totes have been scanned, the MFD Clientmay determine (306) whether any totes are missing from the customerorder. If it is determined that one or more totes are missing from thecustomer order, the MFD Client adds (308) the items associated with themissing totes to a missing item list associated with that customerorder.

At 310, a determination is made as to whether the totes are deliverableto the customer. According to a specific implementation, the customermay authorize an “unattended delivery,” wherein the delivery courier maydeliver the ordered item without obtaining the customer's signature.However, in the event that the customer signature is required fordelivery of the order, and no one is available to sign for the delivery,the order will be reported (312) as undeliverable. When the deliverycourier determines that an order is undeliverable, the courier may enterthis information into the MFD Client, along with selected reasoncode(s). According to a specific embodiment, the MFD Client may thenautomatically assess a re-delivery fee for the customer order. It willbe appreciated that the procedural elements of blocks 310 and 312 mayoccur before the delivery courier unloads the appropriate totes from thedelivery truck.

Assuming that the customer order totes are deliverable, at 314, the MFDClient determines whether an ID check is required for at least a portionof the ordered items. As stated previously, an ID check may be requiredfor ordered items such as tobacco or alcohol. If an ID check isrequired, the MFD Client may instruct a courier to verify information onthe customer's ID. For example, an order includes a carton of cigarettesand a bottle of alcohol, where the minimum smoking age is 18, and theminimum drinking age is 21, the MFD Client may instruct the deliverycourier to verify that the customer is at least 18 to receive the cartonof cigarettes, and may further instruct the courier to verify that thecustomer is at least 21 to receive the ordered bottle of alcohol. At316, the delivery courier performs the ID verification. If, for anyreason, the delivery courier determines that the ID verification hasfailed (e.g., improper ID, under age, etc.) then, at 318, the restricteditems for which the ID check failed are retained by the deliverycourier. Additionally, at 318, the MFD Client may process theundelivered, restricted items as a customer return.

At 320, the courier delivers the totes to the customer. According to aspecific embodiment, as each tote is scanned by the courier using theMFD Client. The MFD Client then adds a separate tote deposit fee to thecustomer order. After the totes have been delivered to the customer, thecourier is able to process (322, 324) any adjustments or customerservice transactions using the MFD Client. According to at least oneembodiment, the MFD Client may be used to process customer servicetransactions (e.g. adjustments) at any time while the delivery courieris at the customer delivery site. As stated previously, the adjustmentswhich may be processed (324) using the MFD Client may include itemreturns, shorts, credits, fees, tote deposits/returns, coupons, etc.

For example, a customer may wish to return a container of milk which waspurchased in an order that was delivered 2 weeks previously. Accordingto a first implementation, the delivery courier may use the MFD Clientto process (324) the returned item by scanning the item's bar code orUPC code. During this processing, the MFD Client may compare the scannedUPC code against a list of UPC codes included in that customer'sdownloaded order history (which, for example, may include all ordereditems within the past 30 days). When a UPC code match is found in thecustomer order history, the price which the customer paid for the itemin the original order is immediately credited back to the customer.Additionally, any tax which the customer paid on the item is alsocredited back to the customer. If more than one UPC code match is found(meaning that more than one container of milk was purchased by thecustomer within the last 30 days), the customer order historyinformation relating to the matched UPC codes can be displayed to thecourier, and the courier may then select the appropriate matched item toensure proper processing of the customer return. Alternatively,according to a different embodiment, the delivery courier may scrollthrough a list of previous ordered items using the MFD Client. The itemsmay be sorted, for example, by order number. When the delivery courierencounters the entry for the previously ordered item which is beingreturned, the courier may then select that item to thereby cause the MFDClient to process (324) the selected item as a customer return. Thecourier may also enter one or more pre-defined reason codes to helpexplain why the customer is returning the item. In this example, thecontainer of milk may be classified as a “scrapped” good, meaning thatit will be disposed of rather than being returned to the distributioncenter for re-sale. Accordingly, the MFD Client need not generate an RMAslip for the returned container of milk.

Using a different example, it will now be assumed that the customerdesires to return 2 unopened boxes of breakfast cereal which wereoriginally purchased as part of a 4-pack. Like the example above, thedelivery courier may use the MFD Client to process (324) the returntransaction(s) for the 2 unopened boxes of cereal. However, in thisexample, the customer will be credited for a pro-rated amount of theoriginal purchase. Thus, for example, if the customer order history datain the MFD Client indicates that the customer originally paid $8.00 forthe 4-pack of cereal, the customer would be credited one-half of thatamount, or $4.00 for the returned items. Additionally, the customer willbe credited a pro-rated amount of tax which the customer paid in theoriginal order. Thus, for example, if the customer originally paid $1.00in tax for the purchase of the 4-pack of cereal, the customer will becredited $0.50, which represents the tax value of the returnedmerchandise. Furthermore, since the returned boxes of cereal may bereturned to the distribution center for re-sale, the MFD Client willgenerate a RMA slip for the returned boxes of cereal. According to aspecific implementation, the MFD Client will add the 2 boxes of cerealto an RMA list associated with the customer order being delivered.

Each time an adjustment and/or customer service transaction is processedby the MFD Client, the MFD Client calculates (326) updated billing datafor the customer order which is being delivered. The updated billingdata may be referred to as zero balance billing data, which correspondsto updated customer billing data that reflects the current balance inthe customer's account, after taking into account all processedtransactions at the customer site using the MFD Client. Thus, forexample, the zero balance billing data may include billing data relatingto the customer order as well as all transactions processed by the MFDClient for that customer. Moreover, according to at least oneembodiment, the net payment amount reflected in the zero balance billingdata will be the exact amount which the customer will be charged orcredited. In this way, the customer will know, at the time of delivery,all charges and credits for which the customer will be billed and/orcredited. This feature is advantageous in that it provides the customerpeace-of-mind in knowing that no additional charges will appear on thecustomer's bill or credit card after the delivery courier returns to thestation.

Once the MFD Client has processed all desired customer transactions andcalculated the updated zero balance billing data, a final receipt isprinted (328) which includes the updated zero balance billing data.According to a specific implementation, the final receipt will show allcredits, returns, fees, and other adjustments processed at the customersite, and will additionally show a revised total amount to be billed tothe customer. The courier then captures (330) the customer signature onthe MFD Client. At the same time, the MFD Client may record the time atwhich the customer signature is captured. At 332, the delivery courieruses the MFD Client to print a RMA slip for any returned items which areto be returned to the distribution center for re-stocking, and affixesthe RMA slip to the tote which contains the returned goods. At thispoint, the delivery of the customer order has been completed, and thedelivery courier may depart to the next delivery stop.

However, at any time before the delivery courier leaves the currentdelivery stop, the customer may request additional adjustments to beprocessed such as, for example, additional returns, credits, shorts,etc. In response, the delivery courier may use the MFD Client to processthe additional transactions in the same manner described above.Thereafter, a new final receipt with updated zero balance billing datawill be printed and delivered to the customer, and a new signature ofthe customer will be captured. Additionally, a new RMA slip may beprinted which will include any additional items to be returned to thedistribution center.

At 334, the delivery courier leaves the current delivery stop and notesthe departure time. According to a specific embodiment, the deliverycourier may depress one or more keys or buttons on the MFD Client toretrieve the next delivery stop information. At that time, the MFDClient may note the current time and record the current time value asthe departure time from the current delivery stop. When the courierarrives at the next delivery stop, the MFD Field Processing Procedure300 may be repeated as described above.

After the delivery courier has completed delivery to all stops on his orher delivery route, the delivery courier returns to the cross-dockstation. Once the delivery courier has arrived at the station, thecourier may then upload the data from the MFD Client to the MFD Server112, as shown, for example, in FIG. 4 of the drawings.

FIG. 4 shows a flow diagram of a MFD Upload Procedure 400 in accordancewith the specific embodiment of the present invention. The Procedure 400of FIG. 4 may be initiated for each delivery courier returning to astation after completing his or her delivery run (e.g., 402). Thedelivery courier then activates the MFD Client to establish (404) aconnection with the MFD Server 112. As stated previously, the connectionwith the MFD Server may be accomplished using a wired interface or,alternatively, a wireless interface. Once the connection with the MFDServer is established, data captured and/or generated by the MFD Clientduring the delivery run is uploaded (406) from the MFD Client to the MFDServer. According to at least one embodiment, the data which is uploadedto the MFD Server may include adjustment data relating to anyadjustments or customer service transactions processed by the MFDClient. The uploaded MFD data may also include customer signature data,time stamp data, reason code data, etc. Once the MFD Server has receivedthe uploaded data from the MFD Client, the MFD Server processes thereceived data, and stores the process data in the Webstore Database 131as shown, for example, in FIG. 5 of the drawings.

According to a specific implementation, each MFD Client may beconfigured to communicate via a wireless communication system with theMFD Server while the delivery courier is making his or her delivery runto the customer sites. For example, the MFD Client may include a radiotransponder which communicates with a radio transceiver forcommunicating with the MFD Server. In this embodiment, it is possiblefor the MFD Client to immediately transmit to the MFD Server any desireddata which the MFD Client captures and/or generates while in the field.For example, the MFD Client may transmit the arrival and departure timesof the delivery courier at specific customer stops in real-time. Usingthis information, a dispatch operator at the cross-dock station is ableto automatically track the status of each delivery courier in the field.Further, according to a specific embodiment, when the communication linkbetween the MFD Client and the MFD Server is broken, the MFD Client isable to store all processed data which it collects and/or generates inthe field and subsequently transmit, via a batched process, the storeddata to the MFD Server when the communication link to the MFD Server isre-established. Further, it will be appreciated that the MFD Client maybe configured to fully perform all functions and operations at timeswhen the MFD Client is unable to communicate with the MFD Server.

FIG. 5 shows a flow diagram of various data flows which occur between anMFD Client 106 a, an MFD Server 112, and a Webstore Database 131, inaccordance with a specific embodiment of the present invention. A firstportion of the data flows (510) may be associated with the MFD DownloadProcedure 200 of FIG. 2. A second portion of the data flows (520) may beassociated with the MFD Upload Procedure 400 of FIG. 4.

Referring to FIG. 5, at (1) the MFD Client 106 a transmits login data tothe MFD Server 112. Once the MFD Client login data is received at theMFD Server, the MFD Server then retrieves login authentication data fromthe Webstore Database 131 in order to authenticate the login datareceived from the MFD Client 106 a. The MFD Server then transmits (5) aresponse to the MFD Client as to whether the login request has beenapproved or denied. Assuming that the login request from the MFD Clienthas been approved, the MFD Client may then transmit a route ID(corresponding to the route of the delivery courier using the MFD Client106 a) in order to retrieve MFD data relating to the specific routecorresponding to the route ID. If the delivery courier is not able toprovide the route ID corresponding to his or her assigned deliveryroute, the courier may access a route list which includes all route IDsfor one or more specific cross-dock stations via the MFD Client. The MFDClient then transmits (7) a request to the MFD Server to retrieve theroute list information. When this request is received at the MFD Server,the MFD Server accesses (9) the Webstore Database (131) to retrieve therequested route list data, and then forwards (11) the retrieved data tothe MFD Client. Once the delivery courier has entered the desired routeID into the MFD Client, the MFD Client transmits (13) a request to theMFD Server to download MFD data corresponding to the specified route ID.When the MFD Server receives the download request, it retrieves (15) theappropriate customer order history and route data (15) from the WebstoreDatabase (131), and transmits (17) the route data history, customerorder history data, and global data to the MFD Client where it isstored. According to a specific embodiment, the global data may include,for example, reason codes with corresponding descriptions, coupon codes,tote deposit values, late delivery credit values, re-delivery feevalues, etc.

As shown in the MFD Upload Procedure 400 of FIG. 4, when the deliverycourier returns to the station, all data processed by the MFD Client maybe uploaded to the MFD Server. This is shown at 19 of FIG. 5, whichillustrates an MFD Client 106 a uploading data to MFD Server 112. Afterthe uploaded data has been received at the MFD Server, the MFD Serverprocesses the received data, and transmits its processed data to theWebstore Database 131. For example, the MFD Server may apply (21) theuploaded adjustment data to the appropriate customer orders and storethis information on the Webstore Database. Additionally, the MFD Servermay store or record (23) the zero balance billing data (generated by theMFD Client 106 a) on the Webstore Database. The zero balance billingdata stored on the Webstore Database may subsequently be used by thecredit card capturing server (116, FIG. 1) for charging or creditingappropriate customer credit card accounts. The MFD Server may also store(25) the signature data captured by the MFD Client device 106 a.Further, the MFD Server may generate and store (27) RMA data on theWebstore Database. The RMA data generated by the MFD Server may bederived from the RMA data generated by the MFD Client 106 a. The RMAdata which is stored on the Webstore Database may be subsequently usedby the Order Management Subsystem for managing inventory records.Additionally, the MFD Server may store (29) on the Webstore Database anyupdated tax data uploaded from the MFD Client 106 a.

It will be appreciated that the technique of the present invention isnot limited to the use of a computerized, mobile, hand-held device suchas the MFD Client described in this application. According to at leastone alternate embodiment of the present invention, the technique of thepresent invention may be implemented using a paper method whereby thevarious functions normally performed by the MFD Client may be performedby the delivery courier using a written format to record the variousfield transactions which occur during the courier's delivery run.Thereafter, when the delivery courier returns to the cross-dock station,he or she may input the recorded field transactions (e.g., recorded onpaper) into a computer system which is connected to a server that isfunctionally similar to the MFD Server 112.

One advantage of the technique of the present invention is that itprovides a means for processing customer service requests and/oradjustments to customer orders at the customer delivery site.Additionally, the technique of the present invention provides a simpleand effective solution for allowing customers to return unwantedproducts, without requiring that the customer package the returnedproduct, obtain a return authorization number, pay for shipping charges,or other burdensome tasks associated with conventional electroniccommerce techniques. Further, unlike conventional techniques, thecustomer may be provided with an updated and finalized bill at the timeof delivery which includes all order modifications, returns, and otheradjustment transactions. In this way, the customer will be informed atthe time of delivery of all charges and/or credits for which thecustomer will be billed or credited.

Although several preferred embodiments of this invention have beendescribed in detail herein with reference to the accompanying drawings,it is to be understood that the invention is not limited to theseprecise embodiments, and at various changes and modifications may beeffected therein by one skilled in the art without departing from thescope of spirit of the invention as defined in the appended claims.

1. A method for facilitating delivery of at least one customer order viaa delivery courier that is assigned a delivery route, the at least onecustomer order including at least one ordered item, the methodcomprising: providing a mobile computing device to the delivery courierto facilitate delivery of the at least one customer order to at leastone customer using customer delivery data; executing an adjustmenttransaction using the mobile computing device at a customer deliverystop corresponding to the at least one customer; downloading customeraccount information from the server computing device to the mobilecomputing device; and displaying updated customer billing data at thecustomer delivery stop based on the customer account information and theadjustment transaction.
 2. The method of claim 1 further comprising:establishing a connection between the server computing device and themobile computing device; and downloading the customer delivery data fromthe server computing device to the mobile computing device.
 3. Themethod of claim 1 further comprising: dispatching the delivery courierto deliver customer orders for the delivery route, wherein theconnection between the server computing device and the mobile computingdevice is implemented using a wireless communication protocol, whereinthe customer delivery data includes customer order history data forcustomers associated with the delivery route and further includesdelivery route information corresponding to the delivery route, andwherein the customer order history includes information relating to allitems ordered by the customers within a specified time period.
 4. Themethod of claim 3 further comprising displaying, using the mobilecomputing device, the delivery route information to the delivery courierto facilitate delivery of orders to customers on the delivery route. 5.The method of claim 1 further comprising recording, at the mobilecomputing device, an arrival time at the customer delivery stop.
 6. Themethod of claim 5 further comprising recording, at the mobile computingdevice, a departure time from the customer delivery stop.
 7. The methodof claim 1 further comprising recording, at the mobile computing device,a time related to the delivery courier delivering an order to acustomer.
 8. The method of claim 1 further comprising transmitting tothe server computing device, via a wireless interface, delivery statusinformation corresponding to a status of the delivery courier on thedelivery route, wherein the delivery status information is generated bythe mobile computing device.
 9. The method of claim 8 further comprisingtracking the status of delivery resources using the transmitted deliverystatus information, wherein the delivery resources include at least oneof the delivery courier and a delivery vehicle.
 10. The method of claim1 further comprising printing a receipt at the customer delivery stopusing the mobile computing device.
 11. The method of claim 10 whereinthe receipt being printed is a final receipt for the at least onecustomer based on the updated customer billing data.
 12. The method ofclaim 1 wherein the adjustment transaction includes processing atransaction related to checking an identification.
 13. The method ofclaim 1 wherein the adjustment transaction includes capturing a customersignature.
 14. A method for facilitating delivery of at least onecustomer order via a delivery courier that is assigned a delivery route,the at least one customer order including at least one ordered item, themethod comprising: establishing a connection between a server computingdevice and a mobile computing device; downloading customer delivery datafrom the server computing device to the mobile computing device;facilitating delivery of the at least one customer order to at least onecustomer using the downloaded customer delivery data; and informing thedelivery courier via the mobile computing device that an identificationcheck is to be performed before delivery of the at least one customerorder is completed.
 15. The method of claim 14 wherein the mobilecomputing device automatically notifies the delivery courier when the atleast one customer order being delivered requires an identificationcheck in order for the at least one customer to receive one or morespecific items from the at least one customer order.
 16. The method ofclaim 15 wherein the one or more specific items are restricted items.17. The method of claim 14 further comprising informing the deliverycourier via the mobile computing device that a customer signature is tobe captured, the customer signature acknowledging delivery of the atleast one customer order.
 18. The method of claim 17 wherein the mobilecomputing device is used to capture the customer signature as well as torecord the time when the customer signature was captured.